Autogenerated HTML docs for v1.7.2.1-95-g3d045
diff --git a/git-pull.html b/git-pull.html index 22b2a0f..56ee4db 100644 --- a/git-pull.html +++ b/git-pull.html
@@ -320,24 +320,60 @@ </div> <h2>SYNOPSIS</h2> <div class="sectionbody"> -<div class="para"><p><em>git pull</em> <options> <repository> <refspec>…</p></div> +<div class="para"><p><em>git pull</em> [options] [<repository> [<refspec>…]]</p></div> </div> <h2 id="_description">DESCRIPTION</h2> <div class="sectionbody"> -<div class="para"><p>Runs <em>git fetch</em> with the given parameters, and calls <em>git merge</em> -to merge the retrieved head(s) into the current branch. -With <tt>--rebase</tt>, calls <em>git rebase</em> instead of <em>git merge</em>.</p></div> -<div class="para"><p>Note that you can use <tt>.</tt> (current directory) as the -<repository> to pull from the local repository — this is useful -when merging local branches into the current branch.</p></div> -<div class="para"><p>Also note that options meant for <em>git pull</em> itself and underlying -<em>git merge</em> must be given before the options meant for <em>git fetch</em>.</p></div> -<div class="para"><p><strong>Warning</strong>: Running <em>git pull</em> (actually, the underlying <em>git merge</em>) +<div class="para"><p>Incorporates changes from a remote repository into the current +branch. In its default mode, <tt>git pull</tt> is shorthand for +<tt>git fetch</tt> followed by <tt>git merge FETCH_HEAD</tt>.</p></div> +<div class="para"><p>More precisely, <em>git pull</em> runs <em>git fetch</em> with the given +parameters and calls <em>git merge</em> to merge the retrieved branch +heads into the current branch. +With <tt>--rebase</tt>, it runs <em>git rebase</em> instead of <em>git merge</em>.</p></div> +<div class="para"><p><repository> should be the name of a remote repository as +passed to <a href="git-fetch.html">git-fetch(1)</a>. <refspec> can name an +arbitrary remote ref (for example, the name of a tag) or even +a collection of refs with corresponding remote tracking branches +(e.g., refs/heads/<strong>:refs/remotes/origin/</strong>), but usually it is +the name of a branch in the remote repository.</p></div> +<div class="para"><p>Default values for <repository> and <branch> are read from the +"remote" and "merge" configuration for the current branch +as set by <a href="git-branch.html">git-branch(1)</a> <tt>--track</tt>.</p></div> +<div class="para"><p>Assume the following history exists and the current branch is +"<tt>master</tt>":</p></div> +<div class="listingblock"> +<div class="content"> +<pre><tt> A---B---C master on origin + / + D---E---F---G master</tt></pre> +</div></div> +<div class="para"><p>Then "<tt>git pull</tt>" will fetch and replay the changes from the remote +<tt>master</tt> branch since it diverged from the local <tt>master</tt> (i.e., <tt>E</tt>) +until its current commit (<tt>C</tt>) on top of <tt>master</tt> and record the +result in a new commit along with the names of the two parent commits +and a log message from the user describing the changes.</p></div> +<div class="listingblock"> +<div class="content"> +<pre><tt> A---B---C remotes/origin/master + / \ + D---E---F---G---H master</tt></pre> +</div></div> +<div class="para"><p>See <a href="git-merge.html">git-merge(1)</a> for details, including how conflicts +are presented and handled.</p></div> +<div class="para"><p>In git 1.7.0 or later, to cancel a conflicting merge, use +<tt>git reset --merge</tt>. <strong>Warning</strong>: In older versions of git, running <em>git pull</em> with uncommitted changes is discouraged: while possible, it leaves you -in a state that is hard to back out of in the case of a conflict.</p></div> +in a state that may be hard to back out of in the case of a conflict.</p></div> +<div class="para"><p>If any of the remote changes overlap with local uncommitted changes, +the merge will be automatically cancelled and the work tree untouched. +It is generally best to get any local changes in working order before +pulling or stash them away with <a href="git-stash.html">git-stash(1)</a>.</p></div> </div> <h2 id="_options">OPTIONS</h2> <div class="sectionbody"> +<div class="para"><p>Options meant for <em>git pull</em> itself and the underlying <em>git merge</em> +must be given before the options meant for <em>git fetch</em>.</p></div> <div class="vlist"><dl> <dt> -q @@ -1217,7 +1253,7 @@ </div> <div id="footer"> <div id="footer-text"> -Last updated 2010-07-21 21:55:31 UTC +Last updated 2010-08-13 02:46:20 UTC </div> </div> </body>
diff --git a/git-pull.txt b/git-pull.txt index ab4de10..c50f7dc 100644 --- a/git-pull.txt +++ b/git-pull.txt
@@ -8,29 +8,72 @@ SYNOPSIS -------- -'git pull' <options> <repository> <refspec>... +'git pull' [options] [<repository> [<refspec>...]] DESCRIPTION ----------- -Runs 'git fetch' with the given parameters, and calls 'git merge' -to merge the retrieved head(s) into the current branch. -With `--rebase`, calls 'git rebase' instead of 'git merge'. -Note that you can use `.` (current directory) as the -<repository> to pull from the local repository -- this is useful -when merging local branches into the current branch. +Incorporates changes from a remote repository into the current +branch. In its default mode, `git pull` is shorthand for +`git fetch` followed by `git merge FETCH_HEAD`. -Also note that options meant for 'git pull' itself and underlying -'git merge' must be given before the options meant for 'git fetch'. +More precisely, 'git pull' runs 'git fetch' with the given +parameters and calls 'git merge' to merge the retrieved branch +heads into the current branch. +With `--rebase`, it runs 'git rebase' instead of 'git merge'. -*Warning*: Running 'git pull' (actually, the underlying 'git merge') +<repository> should be the name of a remote repository as +passed to linkgit:git-fetch[1]. <refspec> can name an +arbitrary remote ref (for example, the name of a tag) or even +a collection of refs with corresponding remote tracking branches +(e.g., refs/heads/*:refs/remotes/origin/*), but usually it is +the name of a branch in the remote repository. + +Default values for <repository> and <branch> are read from the +"remote" and "merge" configuration for the current branch +as set by linkgit:git-branch[1] `--track`. + +Assume the following history exists and the current branch is +"`master`": + +------------ + A---B---C master on origin + / + D---E---F---G master +------------ + +Then "`git pull`" will fetch and replay the changes from the remote +`master` branch since it diverged from the local `master` (i.e., `E`) +until its current commit (`C`) on top of `master` and record the +result in a new commit along with the names of the two parent commits +and a log message from the user describing the changes. + +------------ + A---B---C remotes/origin/master + / \ + D---E---F---G---H master +------------ + +See linkgit:git-merge[1] for details, including how conflicts +are presented and handled. + +In git 1.7.0 or later, to cancel a conflicting merge, use +`git reset --merge`. *Warning*: In older versions of git, running 'git pull' with uncommitted changes is discouraged: while possible, it leaves you -in a state that is hard to back out of in the case of a conflict. +in a state that may be hard to back out of in the case of a conflict. + +If any of the remote changes overlap with local uncommitted changes, +the merge will be automatically cancelled and the work tree untouched. +It is generally best to get any local changes in working order before +pulling or stash them away with linkgit:git-stash[1]. OPTIONS ------- +Options meant for 'git pull' itself and the underlying 'git merge' +must be given before the options meant for 'git fetch'. + -q:: --quiet:: This is passed to both underlying git-fetch to squelch reporting of
diff --git a/git-reset.html b/git-reset.html index 7f459b3..145f31a 100644 --- a/git-reset.html +++ b/git-reset.html
@@ -321,37 +321,52 @@ <h2>SYNOPSIS</h2> <div class="sectionbody"> <div class="verseblock"> -<div class="content"><em>git reset</em> [--mixed | --soft | --hard | --merge | --keep] [-q] [<commit>] -<em>git reset</em> [-q] [<commit>] [--] <paths>… -<em>git reset</em> --patch [<commit>] [--] [<paths>…]</div></div> +<div class="content"><em>git reset</em> [-q] [<commit>] [--] <paths>… +<em>git reset</em> --patch [<commit>] [--] [<paths>…] +<em>git reset</em> [--soft | --mixed | --hard | --merge | --keep] [-q] [<commit>]</div></div> </div> <h2 id="_description">DESCRIPTION</h2> <div class="sectionbody"> -<div class="para"><p>Sets the current head to the specified commit and optionally resets the -index and working tree to match.</p></div> -<div class="para"><p>This command is useful if you notice some small error in a recent -commit (or set of commits) and want to redo that part without showing -the undo in the history.</p></div> -<div class="para"><p>If you want to undo a commit other than the latest on a branch, -<a href="git-revert.html">git-revert(1)</a> is your friend.</p></div> -<div class="para"><p>The second and third forms with <em>paths</em> and/or --patch are used to -revert selected paths in the index from a given commit, without moving -HEAD.</p></div> -</div> -<h2 id="_options">OPTIONS</h2> -<div class="sectionbody"> +<div class="para"><p>In the first and second form, copy entries from <commit> to the index. +In the third form, set the current branch to <commit>, optionally +modifying index and worktree to match. The <commit> defaults to HEAD +in all forms.</p></div> <div class="vlist"><dl> <dt> ---mixed +<em>git reset</em> [-q] [<commit>] [--] <paths>… </dt> <dd> <p> - Resets the index but not the working tree (i.e., the changed files - are preserved but not marked for commit) and reports what has not - been updated. This is the default action. + This form resets the index entries for all <paths> to their + state at the <commit>. (It does not affect the worktree, nor + the current branch.) </p> +<div class="para"><p>This means that <tt>git reset <paths></tt> is the opposite of <tt>git add +<paths></tt>.</p></div> </dd> <dt> +<em>git reset</em> --patch|-p [<commit>] [--] [<paths>…] +</dt> +<dd> +<p> + Interactively select hunks in the difference between the index + and <commit> (defaults to HEAD). The chosen hunks are applied + in reverse to the index. +</p> +<div class="para"><p>This means that <tt>git reset -p</tt> is the opposite of <tt>git add -p</tt> (see +<a href="git-add.html">git-add(1)</a>).</p></div> +</dd> +<dt> +<em>git reset</em> [--<mode>] [<commit>] +</dt> +<dd> +<p> + This form points the current branch to <commit> and then + updates index and working tree according to <mode>, which must + be one of the following: +</p> +<div class="vlist"><dl> +<dt> --soft </dt> <dd> @@ -363,6 +378,16 @@ </p> </dd> <dt> +--mixed +</dt> +<dd> +<p> + Resets the index but not the working tree (i.e., the changed files + are preserved but not marked for commit) and reports what has not + been updated. This is the default action. +</p> +</dd> +<dt> --hard </dt> <dd> @@ -395,21 +420,15 @@ is aborted. </p> </dd> -<dt> --p -</dt> -<dt> ---patch -</dt> -<dd> -<p> - Interactively select hunks in the difference between the index - and <commit> (defaults to HEAD). The chosen hunks are applied - in reverse to the index. -</p> -<div class="para"><p>This means that <tt>git reset -p</tt> is the opposite of <tt>git add -p</tt> (see -<a href="git-add.html">git-add(1)</a>).</p></div> +</dl></div> </dd> +</dl></div> +<div class="para"><p>If you want to undo a commit other than the latest on a branch, +<a href="git-revert.html">git-revert(1)</a> is your friend.</p></div> +</div> +<h2 id="_options">OPTIONS</h2> +<div class="sectionbody"> +<div class="vlist"><dl> <dt> -q </dt> @@ -421,221 +440,12 @@ Be quiet, only report errors. </p> </dd> -<dt> -<commit> -</dt> -<dd> -<p> - Commit to make the current HEAD. If not given defaults to HEAD. -</p> -</dd> </dl></div> </div> -<h2 id="_discussion">DISCUSSION</h2> -<div class="sectionbody"> -<div class="para"><p>The tables below show what happens when running:</p></div> -<div class="listingblock"> -<div class="content"> -<pre><tt>git reset --option target</tt></pre> -</div></div> -<div class="para"><p>to reset the HEAD to another commit (<tt>target</tt>) with the different -reset options depending on the state of the files.</p></div> -<div class="para"><p>In these tables, A, B, C and D are some different states of a -file. For example, the first line of the first table means that if a -file is in state A in the working tree, in state B in the index, in -state C in HEAD and in state D in the target, then "git reset --soft -target" will put the file in state A in the working tree, in state B -in the index and in state D in HEAD.</p></div> -<div class="literalblock"> -<div class="content"> -<pre><tt>working index HEAD target working index HEAD ----------------------------------------------------- - A B C D --soft A B D - --mixed A D D - --hard D D D - --merge (disallowed) - --keep (disallowed)</tt></pre> -</div></div> -<div class="literalblock"> -<div class="content"> -<pre><tt>working index HEAD target working index HEAD ----------------------------------------------------- - A B C C --soft A B C - --mixed A C C - --hard C C C - --merge (disallowed) - --keep A C C</tt></pre> -</div></div> -<div class="literalblock"> -<div class="content"> -<pre><tt>working index HEAD target working index HEAD ----------------------------------------------------- - B B C D --soft B B D - --mixed B D D - --hard D D D - --merge D D D - --keep (disallowed)</tt></pre> -</div></div> -<div class="literalblock"> -<div class="content"> -<pre><tt>working index HEAD target working index HEAD ----------------------------------------------------- - B B C C --soft B B C - --mixed B C C - --hard C C C - --merge C C C - --keep B C C</tt></pre> -</div></div> -<div class="literalblock"> -<div class="content"> -<pre><tt>working index HEAD target working index HEAD ----------------------------------------------------- - B C C D --soft B C D - --mixed B D D - --hard D D D - --merge (disallowed) - --keep (disallowed)</tt></pre> -</div></div> -<div class="literalblock"> -<div class="content"> -<pre><tt>working index HEAD target working index HEAD ----------------------------------------------------- - B C C C --soft B C C - --mixed B C C - --hard C C C - --merge B C C - --keep B C C</tt></pre> -</div></div> -<div class="para"><p>"reset --merge" is meant to be used when resetting out of a conflicted -merge. Any mergy operation guarantees that the work tree file that is -involved in the merge does not have local change wrt the index before -it starts, and that it writes the result out to the work tree. So if -we see some difference between the index and the target and also -between the index and the work tree, then it means that we are not -resetting out from a state that a mergy operation left after failing -with a conflict. That is why we disallow --merge option in this case.</p></div> -<div class="para"><p>"reset --keep" is meant to be used when removing some of the last -commits in the current branch while keeping changes in the working -tree. If there could be conflicts between the changes in the commit we -want to remove and the changes in the working tree we want to keep, -the reset is disallowed. That's why it is disallowed if there are both -changes between the working tree and HEAD, and between HEAD and the -target. To be safe, it is also disallowed when there are unmerged -entries.</p></div> -<div class="para"><p>The following tables show what happens when there are unmerged -entries:</p></div> -<div class="literalblock"> -<div class="content"> -<pre><tt>working index HEAD target working index HEAD ----------------------------------------------------- - X U A B --soft (disallowed) - --mixed X B B - --hard B B B - --merge B B B - --keep (disallowed)</tt></pre> -</div></div> -<div class="literalblock"> -<div class="content"> -<pre><tt>working index HEAD target working index HEAD ----------------------------------------------------- - X U A A --soft (disallowed) - --mixed X A A - --hard A A A - --merge A A A - --keep (disallowed)</tt></pre> -</div></div> -<div class="para"><p>X means any state and U means an unmerged index.</p></div> -</div> -<h2 id="_examples">Examples</h2> +<h2 id="_examples">EXAMPLES</h2> <div class="sectionbody"> <div class="vlist"><dl> <dt> -Undo a commit and redo -</dt> -<dd> -<div class="listingblock"> -<div class="content"> -<pre><tt>$ git commit ... -$ git reset --soft HEAD^ <b>(1)</b> -$ edit <b>(2)</b> -$ git commit -a -c ORIG_HEAD <b>(3)</b></tt></pre> -</div></div> -<div class="colist"><ol> -<li> -<p> -This is most often done when you remembered what you -just committed is incomplete, or you misspelled your commit -message, or both. Leaves working tree as it was before "reset". -</p> -</li> -<li> -<p> -Make corrections to working tree files. -</p> -</li> -<li> -<p> -"reset" copies the old head to .git/ORIG_HEAD; redo the -commit by starting with its log message. If you do not need to -edit the message further, you can give -C option instead. -</p> -<div class="para"><p>See also the --amend option to <a href="git-commit.html">git-commit(1)</a>.</p></div> -</li> -</ol></div> -</dd> -<dt> -Undo commits permanently -</dt> -<dd> -<div class="listingblock"> -<div class="content"> -<pre><tt>$ git commit ... -$ git reset --hard HEAD~3 <b>(1)</b></tt></pre> -</div></div> -<div class="colist"><ol> -<li> -<p> -The last three commits (HEAD, HEAD^, and HEAD~2) were bad -and you do not want to ever see them again. Do <strong>not</strong> do this if -you have already given these commits to somebody else. (See the -"RECOVERING FROM UPSTREAM REBASE" section in <a href="git-rebase.html">git-rebase(1)</a> for -the implications of doing so.) -</p> -</li> -</ol></div> -</dd> -<dt> -Undo a commit, making it a topic branch -</dt> -<dd> -<div class="listingblock"> -<div class="content"> -<pre><tt>$ git branch topic/wip <b>(1)</b> -$ git reset --hard HEAD~3 <b>(2)</b> -$ git checkout topic/wip <b>(3)</b></tt></pre> -</div></div> -<div class="colist"><ol> -<li> -<p> -You have made some commits, but realize they were premature -to be in the "master" branch. You want to continue polishing -them in a topic branch, so create "topic/wip" branch off of the -current HEAD. -</p> -</li> -<li> -<p> -Rewind the master branch to get rid of those three commits. -</p> -</li> -<li> -<p> -Switch to "topic/wip" branch and keep working. -</p> -</li> -</ol></div> -</dd> -<dt> Undo add </dt> <dd> @@ -679,6 +489,92 @@ </ol></div> </dd> <dt> +Undo a commit and redo +</dt> +<dd> +<div class="listingblock"> +<div class="content"> +<pre><tt>$ git commit ... +$ git reset --soft HEAD^ <b>(1)</b> +$ edit <b>(2)</b> +$ git commit -a -c ORIG_HEAD <b>(3)</b></tt></pre> +</div></div> +<div class="colist"><ol> +<li> +<p> +This is most often done when you remembered what you +just committed is incomplete, or you misspelled your commit +message, or both. Leaves working tree as it was before "reset". +</p> +</li> +<li> +<p> +Make corrections to working tree files. +</p> +</li> +<li> +<p> +"reset" copies the old head to .git/ORIG_HEAD; redo the +commit by starting with its log message. If you do not need to +edit the message further, you can give -C option instead. +</p> +<div class="para"><p>See also the --amend option to <a href="git-commit.html">git-commit(1)</a>.</p></div> +</li> +</ol></div> +</dd> +<dt> +Undo a commit, making it a topic branch +</dt> +<dd> +<div class="listingblock"> +<div class="content"> +<pre><tt>$ git branch topic/wip <b>(1)</b> +$ git reset --hard HEAD~3 <b>(2)</b> +$ git checkout topic/wip <b>(3)</b></tt></pre> +</div></div> +<div class="colist"><ol> +<li> +<p> +You have made some commits, but realize they were premature +to be in the "master" branch. You want to continue polishing +them in a topic branch, so create "topic/wip" branch off of the +current HEAD. +</p> +</li> +<li> +<p> +Rewind the master branch to get rid of those three commits. +</p> +</li> +<li> +<p> +Switch to "topic/wip" branch and keep working. +</p> +</li> +</ol></div> +</dd> +<dt> +Undo commits permanently +</dt> +<dd> +<div class="listingblock"> +<div class="content"> +<pre><tt>$ git commit ... +$ git reset --hard HEAD~3 <b>(1)</b></tt></pre> +</div></div> +<div class="colist"><ol> +<li> +<p> +The last three commits (HEAD, HEAD^, and HEAD~2) were bad +and you do not want to ever see them again. Do <strong>not</strong> do this if +you have already given these commits to somebody else. (See the +"RECOVERING FROM UPSTREAM REBASE" section in <a href="git-rebase.html">git-rebase(1)</a> for +the implications of doing so.) +</p> +</li> +</ol></div> +</dd> +<dt> Undo a merge or pull </dt> <dd> @@ -876,6 +772,121 @@ </dd> </dl></div> </div> +<h2 id="_discussion">DISCUSSION</h2> +<div class="sectionbody"> +<div class="para"><p>The tables below show what happens when running:</p></div> +<div class="listingblock"> +<div class="content"> +<pre><tt>git reset --option target</tt></pre> +</div></div> +<div class="para"><p>to reset the HEAD to another commit (<tt>target</tt>) with the different +reset options depending on the state of the files.</p></div> +<div class="para"><p>In these tables, A, B, C and D are some different states of a +file. For example, the first line of the first table means that if a +file is in state A in the working tree, in state B in the index, in +state C in HEAD and in state D in the target, then "git reset --soft +target" will put the file in state A in the working tree, in state B +in the index and in state D in HEAD.</p></div> +<div class="literalblock"> +<div class="content"> +<pre><tt>working index HEAD target working index HEAD +---------------------------------------------------- + A B C D --soft A B D + --mixed A D D + --hard D D D + --merge (disallowed) + --keep (disallowed)</tt></pre> +</div></div> +<div class="literalblock"> +<div class="content"> +<pre><tt>working index HEAD target working index HEAD +---------------------------------------------------- + A B C C --soft A B C + --mixed A C C + --hard C C C + --merge (disallowed) + --keep A C C</tt></pre> +</div></div> +<div class="literalblock"> +<div class="content"> +<pre><tt>working index HEAD target working index HEAD +---------------------------------------------------- + B B C D --soft B B D + --mixed B D D + --hard D D D + --merge D D D + --keep (disallowed)</tt></pre> +</div></div> +<div class="literalblock"> +<div class="content"> +<pre><tt>working index HEAD target working index HEAD +---------------------------------------------------- + B B C C --soft B B C + --mixed B C C + --hard C C C + --merge C C C + --keep B C C</tt></pre> +</div></div> +<div class="literalblock"> +<div class="content"> +<pre><tt>working index HEAD target working index HEAD +---------------------------------------------------- + B C C D --soft B C D + --mixed B D D + --hard D D D + --merge (disallowed) + --keep (disallowed)</tt></pre> +</div></div> +<div class="literalblock"> +<div class="content"> +<pre><tt>working index HEAD target working index HEAD +---------------------------------------------------- + B C C C --soft B C C + --mixed B C C + --hard C C C + --merge B C C + --keep B C C</tt></pre> +</div></div> +<div class="para"><p>"reset --merge" is meant to be used when resetting out of a conflicted +merge. Any mergy operation guarantees that the work tree file that is +involved in the merge does not have local change wrt the index before +it starts, and that it writes the result out to the work tree. So if +we see some difference between the index and the target and also +between the index and the work tree, then it means that we are not +resetting out from a state that a mergy operation left after failing +with a conflict. That is why we disallow --merge option in this case.</p></div> +<div class="para"><p>"reset --keep" is meant to be used when removing some of the last +commits in the current branch while keeping changes in the working +tree. If there could be conflicts between the changes in the commit we +want to remove and the changes in the working tree we want to keep, +the reset is disallowed. That's why it is disallowed if there are both +changes between the working tree and HEAD, and between HEAD and the +target. To be safe, it is also disallowed when there are unmerged +entries.</p></div> +<div class="para"><p>The following tables show what happens when there are unmerged +entries:</p></div> +<div class="literalblock"> +<div class="content"> +<pre><tt>working index HEAD target working index HEAD +---------------------------------------------------- + X U A B --soft (disallowed) + --mixed X B B + --hard B B B + --merge B B B + --keep (disallowed)</tt></pre> +</div></div> +<div class="literalblock"> +<div class="content"> +<pre><tt>working index HEAD target working index HEAD +---------------------------------------------------- + X U A A --soft (disallowed) + --mixed X A A + --hard A A A + --merge A A A + --keep (disallowed)</tt></pre> +</div></div> +<div class="para"><p>X means any state and U means an unmerged index.</p></div> +</div> <h2 id="_author">Author</h2> <div class="sectionbody"> <div class="para"><p>Written by Junio C Hamano <gitster@pobox.com> and Linus Torvalds <torvalds@osdl.org></p></div> @@ -890,7 +901,7 @@ </div> <div id="footer"> <div id="footer-text"> -Last updated 2010-07-21 21:55:34 UTC +Last updated 2010-08-13 02:46:20 UTC </div> </div> </body>
diff --git a/git-reset.txt b/git-reset.txt index 645f0c1..b04d129 100644 --- a/git-reset.txt +++ b/git-reset.txt
@@ -8,40 +8,50 @@ SYNOPSIS -------- [verse] -'git reset' [--mixed | --soft | --hard | --merge | --keep] [-q] [<commit>] 'git reset' [-q] [<commit>] [--] <paths>... 'git reset' --patch [<commit>] [--] [<paths>...] +'git reset' [--soft | --mixed | --hard | --merge | --keep] [-q] [<commit>] DESCRIPTION ----------- -Sets the current head to the specified commit and optionally resets the -index and working tree to match. +In the first and second form, copy entries from <commit> to the index. +In the third form, set the current branch to <commit>, optionally +modifying index and worktree to match. The <commit> defaults to HEAD +in all forms. -This command is useful if you notice some small error in a recent -commit (or set of commits) and want to redo that part without showing -the undo in the history. +'git reset' [-q] [<commit>] [--] <paths>...:: + This form resets the index entries for all <paths> to their + state at the <commit>. (It does not affect the worktree, nor + the current branch.) ++ +This means that `git reset <paths>` is the opposite of `git add +<paths>`. -If you want to undo a commit other than the latest on a branch, -linkgit:git-revert[1] is your friend. +'git reset' --patch|-p [<commit>] [--] [<paths>...]:: + Interactively select hunks in the difference between the index + and <commit> (defaults to HEAD). The chosen hunks are applied + in reverse to the index. ++ +This means that `git reset -p` is the opposite of `git add -p` (see +linkgit:git-add[1]). -The second and third forms with 'paths' and/or --patch are used to -revert selected paths in the index from a given commit, without moving -HEAD. - - -OPTIONS -------- ---mixed:: - Resets the index but not the working tree (i.e., the changed files - are preserved but not marked for commit) and reports what has not - been updated. This is the default action. - +'git reset' [--<mode>] [<commit>]:: + This form points the current branch to <commit> and then + updates index and working tree according to <mode>, which must + be one of the following: ++ +-- --soft:: Does not touch the index file nor the working tree at all, but requires them to be in a good order. This leaves all your changed files "Changes to be committed", as 'git status' would put it. +--mixed:: + Resets the index but not the working tree (i.e., the changed files + are preserved but not marked for commit) and reports what has not + been updated. This is the default action. + --hard:: Matches the working tree and index to that of the tree being switched to. Any changes to tracked files in the working tree @@ -59,179 +69,23 @@ the given commit. If a file that is different between the current commit and the given commit has local changes, reset is aborted. +-- --p:: ---patch:: - Interactively select hunks in the difference between the index - and <commit> (defaults to HEAD). The chosen hunks are applied - in reverse to the index. -+ -This means that `git reset -p` is the opposite of `git add -p` (see -linkgit:git-add[1]). +If you want to undo a commit other than the latest on a branch, +linkgit:git-revert[1] is your friend. + + +OPTIONS +------- -q:: --quiet:: Be quiet, only report errors. -<commit>:: - Commit to make the current HEAD. If not given defaults to HEAD. -DISCUSSION ----------- - -The tables below show what happens when running: - ----------- -git reset --option target ----------- - -to reset the HEAD to another commit (`target`) with the different -reset options depending on the state of the files. - -In these tables, A, B, C and D are some different states of a -file. For example, the first line of the first table means that if a -file is in state A in the working tree, in state B in the index, in -state C in HEAD and in state D in the target, then "git reset --soft -target" will put the file in state A in the working tree, in state B -in the index and in state D in HEAD. - - working index HEAD target working index HEAD - ---------------------------------------------------- - A B C D --soft A B D - --mixed A D D - --hard D D D - --merge (disallowed) - --keep (disallowed) - - working index HEAD target working index HEAD - ---------------------------------------------------- - A B C C --soft A B C - --mixed A C C - --hard C C C - --merge (disallowed) - --keep A C C - - working index HEAD target working index HEAD - ---------------------------------------------------- - B B C D --soft B B D - --mixed B D D - --hard D D D - --merge D D D - --keep (disallowed) - - working index HEAD target working index HEAD - ---------------------------------------------------- - B B C C --soft B B C - --mixed B C C - --hard C C C - --merge C C C - --keep B C C - - working index HEAD target working index HEAD - ---------------------------------------------------- - B C C D --soft B C D - --mixed B D D - --hard D D D - --merge (disallowed) - --keep (disallowed) - - working index HEAD target working index HEAD - ---------------------------------------------------- - B C C C --soft B C C - --mixed B C C - --hard C C C - --merge B C C - --keep B C C - -"reset --merge" is meant to be used when resetting out of a conflicted -merge. Any mergy operation guarantees that the work tree file that is -involved in the merge does not have local change wrt the index before -it starts, and that it writes the result out to the work tree. So if -we see some difference between the index and the target and also -between the index and the work tree, then it means that we are not -resetting out from a state that a mergy operation left after failing -with a conflict. That is why we disallow --merge option in this case. - -"reset --keep" is meant to be used when removing some of the last -commits in the current branch while keeping changes in the working -tree. If there could be conflicts between the changes in the commit we -want to remove and the changes in the working tree we want to keep, -the reset is disallowed. That's why it is disallowed if there are both -changes between the working tree and HEAD, and between HEAD and the -target. To be safe, it is also disallowed when there are unmerged -entries. - -The following tables show what happens when there are unmerged -entries: - - working index HEAD target working index HEAD - ---------------------------------------------------- - X U A B --soft (disallowed) - --mixed X B B - --hard B B B - --merge B B B - --keep (disallowed) - - working index HEAD target working index HEAD - ---------------------------------------------------- - X U A A --soft (disallowed) - --mixed X A A - --hard A A A - --merge A A A - --keep (disallowed) - -X means any state and U means an unmerged index. - -Examples +EXAMPLES -------- -Undo a commit and redo:: -+ ------------- -$ git commit ... -$ git reset --soft HEAD^ <1> -$ edit <2> -$ git commit -a -c ORIG_HEAD <3> ------------- -+ -<1> This is most often done when you remembered what you -just committed is incomplete, or you misspelled your commit -message, or both. Leaves working tree as it was before "reset". -<2> Make corrections to working tree files. -<3> "reset" copies the old head to .git/ORIG_HEAD; redo the -commit by starting with its log message. If you do not need to -edit the message further, you can give -C option instead. -+ -See also the --amend option to linkgit:git-commit[1]. - -Undo commits permanently:: -+ ------------- -$ git commit ... -$ git reset --hard HEAD~3 <1> ------------- -+ -<1> The last three commits (HEAD, HEAD^, and HEAD~2) were bad -and you do not want to ever see them again. Do *not* do this if -you have already given these commits to somebody else. (See the -"RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1] for -the implications of doing so.) - -Undo a commit, making it a topic branch:: -+ ------------- -$ git branch topic/wip <1> -$ git reset --hard HEAD~3 <2> -$ git checkout topic/wip <3> ------------- -+ -<1> You have made some commits, but realize they were premature -to be in the "master" branch. You want to continue polishing -them in a topic branch, so create "topic/wip" branch off of the -current HEAD. -<2> Rewind the master branch to get rid of those three commits. -<3> Switch to "topic/wip" branch and keep working. - Undo add:: + ------------ @@ -255,6 +109,53 @@ <4> Then you can pull and merge, leaving frotz.c and filfre.c changes still in the working tree. +Undo a commit and redo:: ++ +------------ +$ git commit ... +$ git reset --soft HEAD^ <1> +$ edit <2> +$ git commit -a -c ORIG_HEAD <3> +------------ ++ +<1> This is most often done when you remembered what you +just committed is incomplete, or you misspelled your commit +message, or both. Leaves working tree as it was before "reset". +<2> Make corrections to working tree files. +<3> "reset" copies the old head to .git/ORIG_HEAD; redo the +commit by starting with its log message. If you do not need to +edit the message further, you can give -C option instead. ++ +See also the --amend option to linkgit:git-commit[1]. + +Undo a commit, making it a topic branch:: ++ +------------ +$ git branch topic/wip <1> +$ git reset --hard HEAD~3 <2> +$ git checkout topic/wip <3> +------------ ++ +<1> You have made some commits, but realize they were premature +to be in the "master" branch. You want to continue polishing +them in a topic branch, so create "topic/wip" branch off of the +current HEAD. +<2> Rewind the master branch to get rid of those three commits. +<3> Switch to "topic/wip" branch and keep working. + +Undo commits permanently:: ++ +------------ +$ git commit ... +$ git reset --hard HEAD~3 <1> +------------ ++ +<1> The last three commits (HEAD, HEAD^, and HEAD~2) were bad +and you do not want to ever see them again. Do *not* do this if +you have already given these commits to somebody else. (See the +"RECOVERING FROM UPSTREAM REBASE" section in linkgit:git-rebase[1] for +the implications of doing so.) + Undo a merge or pull:: + ------------ @@ -376,6 +277,114 @@ <3> But you can use "reset --keep" to remove the unwanted commit after you switched to "branch2". + +DISCUSSION +---------- + +The tables below show what happens when running: + +---------- +git reset --option target +---------- + +to reset the HEAD to another commit (`target`) with the different +reset options depending on the state of the files. + +In these tables, A, B, C and D are some different states of a +file. For example, the first line of the first table means that if a +file is in state A in the working tree, in state B in the index, in +state C in HEAD and in state D in the target, then "git reset --soft +target" will put the file in state A in the working tree, in state B +in the index and in state D in HEAD. + + working index HEAD target working index HEAD + ---------------------------------------------------- + A B C D --soft A B D + --mixed A D D + --hard D D D + --merge (disallowed) + --keep (disallowed) + + working index HEAD target working index HEAD + ---------------------------------------------------- + A B C C --soft A B C + --mixed A C C + --hard C C C + --merge (disallowed) + --keep A C C + + working index HEAD target working index HEAD + ---------------------------------------------------- + B B C D --soft B B D + --mixed B D D + --hard D D D + --merge D D D + --keep (disallowed) + + working index HEAD target working index HEAD + ---------------------------------------------------- + B B C C --soft B B C + --mixed B C C + --hard C C C + --merge C C C + --keep B C C + + working index HEAD target working index HEAD + ---------------------------------------------------- + B C C D --soft B C D + --mixed B D D + --hard D D D + --merge (disallowed) + --keep (disallowed) + + working index HEAD target working index HEAD + ---------------------------------------------------- + B C C C --soft B C C + --mixed B C C + --hard C C C + --merge B C C + --keep B C C + +"reset --merge" is meant to be used when resetting out of a conflicted +merge. Any mergy operation guarantees that the work tree file that is +involved in the merge does not have local change wrt the index before +it starts, and that it writes the result out to the work tree. So if +we see some difference between the index and the target and also +between the index and the work tree, then it means that we are not +resetting out from a state that a mergy operation left after failing +with a conflict. That is why we disallow --merge option in this case. + +"reset --keep" is meant to be used when removing some of the last +commits in the current branch while keeping changes in the working +tree. If there could be conflicts between the changes in the commit we +want to remove and the changes in the working tree we want to keep, +the reset is disallowed. That's why it is disallowed if there are both +changes between the working tree and HEAD, and between HEAD and the +target. To be safe, it is also disallowed when there are unmerged +entries. + +The following tables show what happens when there are unmerged +entries: + + working index HEAD target working index HEAD + ---------------------------------------------------- + X U A B --soft (disallowed) + --mixed X B B + --hard B B B + --merge B B B + --keep (disallowed) + + working index HEAD target working index HEAD + ---------------------------------------------------- + X U A A --soft (disallowed) + --mixed X A A + --hard A A A + --merge A A A + --keep (disallowed) + +X means any state and U means an unmerged index. + + Author ------ Written by Junio C Hamano <gitster@pobox.com> and Linus Torvalds <torvalds@osdl.org>
